A packet switching system, such as may be used in telephony, is generally made up of a plurality of packet switches interconnected by communication links such as telephone trunks. A packet switch commonly comprises a packet switching network for selectively connecting various of its inputs to various of its outputs; trunk controllers each for interfacing a communication link to an input and an output of the packet switching network; and a central processor for controlling the operation of the switch. Such packet switches and systems are known in the art. An example thereof is disclosed in the copending U.S. patent application of Jonathan S. Turner, entitled "An Interface Facility for a Packet Switching System", U.S. patent application Ser. No. 392,228, filed on June 25, 1982, issued on Dec. 11, 1984, as U.S. Pat. No. 4,488,289, and assigned to the same assignee as this application.
The call path setup procedure in such a system commonly requires that the central processor at each switch respond to the receipt over an incoming trunk of a call setup packet by assigning an outgoing trunk to the call and transmitting the call setup packet on the outgoing trunk to the next switch or other equipment. This process is repeated at each switch until a complete path interconnecting the calling party with the called party is set up for the call. Assigned trunks are not generally dedicated to a single call at a time. Rather, they are commonly shared by a plurality of simultaneous calls. Hence the trunks, and their associated trunk controllers, are treated by the central processor as physical resources to be shared by the interconnection paths of a plurality of calls. Each central processor keeps track of the status of the switch's trunk controllers and assigns the trunk controllers and their associated trunks as links in various interconnection paths.
The central processor assigns trunk controllers to interconnection paths in a manner that seeks to distribute call traffic evenly between alternative trunk controllers, to maximize information flow through the switch. This is a difficult task, however, because conventionally the central processor has no knowledge of the amount of information that is or will be transmitted by a call over a path, and hence has no knowledge of the call traffic being served by a trunk controller.
An approach taken in the past has been for the central processor to assign alternative trunk controllers to call paths in a round-robin fashion, to more or less equalize the number of calls that each trunk controller is assigned to serve. This policy of trunk controller assignment would be satisfactory if the traffic of each call were approximately the same. However, the traffic of different calls commonly varies considerably. As a result, this approach often does not balance the traffic load of the various trunk controllers. Consequently, undesired delay of packets, and possibly even loss of packets or of entire calls, may occur in trunk controllers that are heavily loaded or overloaded with traffic. At the same time, no appreciable delay may occur for call packets served by other trunk controllers, and these other trunk controllers may even be idle for periods of time even though the underloaded controllers are serving a number of calls that is the same as or greater than the number of calls being served by the overloaded controllers. Resultingly, the prior art, in such situations, has not been equipped to distribute calls among alternative trunk controllers in a manner that would equalize the traffic load served by a controller and that would prevent such trunk controllers from becoming overloaded.